Docs for 2.3 - #34

Signed-off-by: The Architect <hello@ingestron.io>

… limits

- Start from a published standard, Move to a newer one and the CLI
  reference: the name alone takes the newest version that is not a
  preview among the installed versions and the catalogue's tags, or the
  newest installed with a note when the catalogue cannot be reached.
- The Databricks kit's page: project.yaml holds the two groups.
- Share a template: reading tags for a name alone uses the network; git
  and ssh never ask for a password; the 15 and 60 second limits.
- Tests: the note as init prints it, and each group's line in
  project.yaml.

Signed-off-by: The Architect <hello@ingestron.io>

Signed-off-by: The Architect <hello@ingestron.io>

Signed-off-by: The Architect <hello@ingestron.io>

…rning

The intent vocabulary describes the quality and cleansing paths: rule
kinds and table checks are written in the contract, actions in the
standard, a layer or an expectation, and each cleansing operation where
its column is cleansed.

The DuckDB starter's required order_id is now NOT_APPLIED in every plan,
since its layers say nothing of checking, so the first project, adding a
source and their tests show and explain that warning. The quality table
says where DuckDB and Synapse check rows and what is NOT_APPLIED.

Signed-off-by: The Architect <hello@ingestron.io>

The quality example is one contract's checks on Databricks, DuckDB and
Synapse, an environment each, and Check data quality is rewritten around
it: where checks run by layer, warn, drop and fail, table checks,
quarantine and results, and the engine table from each pack's coverage.

New pages: Not applied here (what the state means, where it shows, how it
differs from other warnings and CAPABILITY_OFF, and the does hint);
Cleanse data in the right layer, on the DuckDB published standard, with a
transform without code and timestamps to UTC; and Accept a warning, for
every environment or through a value.

Each pack's page gains Quality and cleansing from its coverage, with the
layers each value needs and its sources; Synapse lists the zones it
cannot convert. The errors page says how each code is reported and marks
CONTRACT_FIELD_UNUSED removed. Layers, the intent and documents reference,
contracts, transforms, the platform pages, troubleshooting and the kits
say what layer duties, cleansing and accepted warnings change.

Signed-off-by: The Architect <hello@ingestron.io>

…rnings

The 2.3 notes say that passports rewrite their Quality section, that
DuckDB and Synapse check rows only where a layer's does says so and need
nothing turned on for table checks, which old codes became NOT_APPLIED
or CAPABILITY_OFF, and that a warning can be accepted. The package notes
list the quality and cleansing additions.

Signed-off-by: The Architect <hello@ingestron.io>

duckdb-local, data-products and synapse-views give each layer its does:
bronze keeps raw rows and counts its checks, silver and gold check. Their
plans no longer list NOT_APPLIED for required columns, the data-products
passport says what checks each table, and Synapse writes checks.sql,
which its platform and pack pages now list. Not applied here describes
the passport in words, and the test that shows the does hint on Synapse
takes the duties away first.

Signed-off-by: The Architect <hello@ingestron.io>

A table Lakeflow Connect writes still runs its table checks after each
refresh, and the event log keeps results; only its row checks, actions,
quarantine, cleansing and deduplicate are not applied. Check data quality
shows the VS Code way to plan again; Accept a warning says entries for
build-only warnings are judged only when the packs build; a custom rule
is one only another engine could run.

Signed-off-by: The Architect <hello@ingestron.io>

Describe the governance part of the streaming lakehouse kit, move the line
number its NOT_APPLIED sample shows, and expect the kit's new REPLACE_ME
values.

Signed-off-by: The Architect <hello@ingestron.io>

A guide to granting access, masking columns and filtering rows, the
governed-databricks example, roles and grants in synapse-views, and an
accepted NOT_APPLIED in data-products. Each pack's page lists its access
coverage, Synapse's page its platform section, and the intent reference
the access paths. The upgrade notes list the new warnings and output
changes.

Signed-off-by: The Architect <hello@ingestron.io>

Filter wording, Synapse masks and filters in the upgrade notes, who the
policies exempt, links to each pack's access, roles and masks on the
contract page, when to run the SQL after the first deploy, and a unique
order for the new example.

Signed-off-by: The Architect <hello@ingestron.io>

The ask-the-platform-team page names the Synapse switch beside the Databricks ones, as the request lists it.

Signed-off-by: The Architect <hello@ingestron.io>

The Databricks apply task makes its policies before it grants, and the pages
say so. Masks hide values in the tables, not in the files ADF lands. Synapse
exact grants keep the permissions of the user that runs views.sql. The
upgrade page lists the per-pack request and the single classification tag,
and the platform team page gives a Synapse example of a switch that is off.

Signed-off-by: The Architect <hello@ingestron.io>

…ers filled in

Signed-off-by: The Architect <hello@ingestron.io>

Signed-off-by: The Architect <hello@ingestron.io>